home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 1 / QRZ Ham Radio Callsign Database - December 1993.iso / ucsd / drivers.arc / PACKETQA.TXT < prev    next >
Encoding:
Text File  |  1988-07-25  |  5.4 KB  |  115 lines
  1. Several questions on the packet driver, revision 1.05:
  2.  
  3. Q: Are there any PD packet drivers?  Specifically, SLIP, 3c501 or NI5210?
  4.  
  5. A: Karl Auerbach (karl@trwind.trw.com) did a version of the CMU PCIP that
  6.    calls the spec.  He has also implemented a Packet Driver, for TRW's
  7.    card.  I don't know if that Packet Driver is public or not.  I believe
  8.    that all the others are private (most are part of Netware or other LAN
  9.    program TSR modules).
  10.  
  11. Q: (p.3, last paragraph) Why does an application program have to check
  12.    the class and type returned from a driver_info() call?  If the program
  13.    explicitly asks for a given class, and that request succeeded, why check
  14.    the type?  Isn't that what the driver is supposed to be masking?
  15.  
  16. A: My crock.  The access_type() will fail if the driver is for the wrong
  17.    kind of interface, so a driver_info() isn't needed.
  18.  
  19. C: So the way to enumerate all the interfaces is to look for "PKT DRVR",
  20.    issue a access_type() with wildcards, and do a driver_info() to determine
  21.    what kind of driver has been accessed.
  22.  
  23.  
  24. Q: If each interface is supposed to have its own interrupt, why specify a
  25.    handle?
  26. A: A handle is needed because a) you need to ask for several different packet
  27.    types to effectively use IP, and you may want to manipulate them
  28.    separately, and b) because the Packet Driver needs to be able to tell
  29.    application A (IP) from application B (random TSR).  Under DOS,
  30.    multiple programs can use one interface, but different packet types
  31.    (provided they hack DOS well enough to run at the same time).
  32.  
  33. C: Right.  I missed the "type" specification.  I'm not exactly sure what the
  34.    type specification should contain.  It seems to be dependent upon the
  35.    interface class.  Is this type specification "clearly obvious to the
  36.    expert" (which I'm not yet)?
  37.  
  38. A: On DEC-Intel-Xerox ("Blue Book") Ethernet, which is what the whole world of
  39.    TCP/IP is using right now, the "type" is assumed to be the 2-byte
  40.    Ethertype (0x800 for IP, 0x806 for ARP, etc.).  On ProNET-10, it would
  41.    be the 1-byte packet type, on 802.5 it would be at least 2 bytes (SSAP,
  42.    DSAP), and might be considerably longer, for instance to cover all 8
  43.    bytes of a SNAP encapsulation.  That is why we include a length.
  44.  
  45.  
  46. Q: In the same vein, why specify access_type if there is only one interface
  47.    per interrupt?
  48. A. The same reason as above.
  49.  
  50.  
  51. Q: There is no provision for reporting cause of errors, i.e. jam, shorts,
  52.    etc.  Perhaps get_statistics() should return, as part of the statistics
  53.    structure, long errors[10] and char errnames[20][10], where the last is
  54.    the name of the error.
  55. A: That approach only succeeds if the program making the get_statistics()
  56.    call can use the strings directly.  In the case of our 2.0 TSR kernel,
  57.    or with other TSR (LAN program redirectors, etc.), the names aren't
  58.    used because the numbers just get saved, or stuffed into format
  59.    (different) of our net_stats() call.  Programs that call our kernel are
  60.    hardware-independent, so they wouldn't know to do the get_statistics()
  61.    call.
  62.  
  63. C: I hadn't intended that these error counts be useful to the program -- merely
  64.    useful for a system jock who's trying to debug his code.
  65.  
  66. A: I would recommend that any actual debugging of a new hardware driver take
  67.    place when it is linked into a normal DOS program (like PCIP).  Then,
  68.    once it is working right, move it into the Packet Driver TSR.  TSRs are
  69.    awfully hard to debug...
  70.  
  71. In the function access_type():
  72.  
  73. Q: What is the range of if_number?
  74.  
  75. A: if_number is somewhat of an appendix.  Due to other aspects of the design
  76.    (no handle on the send_pkt call), the only reasonable value is 0.
  77.  
  78. Q: When should access_type return BAD_HANDLE?  When out of handles?
  79.  
  80. A: access_type() can return BAD_HANDLE when out of handles.
  81.  
  82. Q: When should access_type return TYPE_INUSE?  When the packet type is in use?
  83.  
  84. A: TYPE_INUSE is intended for just that situation: someone else has
  85.    already claimed either the type specified or some superset of it.
  86.  
  87. Q: Why is typelen a parameter?  Isn't it a fixed quantity for each
  88.    interface class?
  89.  
  90. A: typelen is a parameter to allow for situations (802.2 packet headers is
  91.    the only case I can think of at the moment) where the match length
  92.    varies.  With 802.2 headers, one application might want all packets
  93.    with SSAP 1, and another might want SSAP = 1, DSAP = 2, etc.  In
  94.    conventional Blue-Book Ethernet, typelen is effectively a constant, 2.
  95.  
  96. Q: What if I don't have enough space to store their type? Return NO_SPACE?
  97.  
  98. A: NO_SPACE is intended for any kind of resource exhaustion that makes the
  99.    access_type() fail.
  100.  
  101. In the function terminate():
  102.  
  103. Q: Sounds like the driver shouldn't terminate until and unless all handles
  104.    have either been released.  What if a call to terminate() has been
  105.    made, and there are other handles in use?  Should the driver terminate
  106.    after the last handle has been released?  Sounds like terminate()
  107.    requires a handle that *hasn't* been released.  If it returns
  108.    CANT_TERMINATE, should it also release the handle?
  109.  
  110. A: I hadn't throught about terminate() much.  Seems like a good idea to
  111.    release the handle, whether or not the call succeeds.  This would allow
  112.    an application to attempt to free up all memory by closing all its
  113.    handles that way (although if this succeeded, the packet driver would
  114.    need to be re-started before another network program could run).
  115.